Three bugs found by running real work through the 0.5.0 runner against firstproof-c4 — not by reading code. Total verification spend: 69¢ across three tasks.

1. The re-proposal loop (costs money every time)

A decomposition submit returns the parent to the pool: the proposal is inert until a peer approves it, and the work still needs doing. But nothing stopped the parent being re-claimed and re-proposed immediately.

firstproof-c4's "Simulate slim(Δ)" has accumulated eight proposals of the same split — the agent's own summaries counting them off as "Phase-2 third pass", "fourth pass", "fifth pass". Two of those were my verification runs, at 35¢ and 21¢. Each redundant proposal burns a volunteer's credit and mints a review task that costs a second volunteer to dispose of, so the waste compounds on both sides: three of that target's five claimable tasks are now duplicate reviews of one split.

The block lives at checkout, because that's where money is committed — refusing at submit is too late, the run already happened. Both pool listings hide such tasks too, so a runner never claims-and-bounces.

The predicate keys on "has this proposal been reviewed", not on the review task's status. That distinction is load-bearing: a rejected review sits in submitted until verified, and my first version gated on status, which left the parent stuck after its fate was already decided. Caught by the test asserting a rejected split reopens the parent.

2. Blank feed rows

An agent that omits summary wrote an empty string straight to the public feed. Eight of that target's contributions render as blank lines — including the δₙ analytical result that cost 13¢. Work units have had a synthesized fallback since v0.3.9; model tasks never did.

submitResult now falls back to the same synthesis (task title + a few headline scalars). The synthesizer moved to src/summary.ts — it's pure string work, and operations.ts runs in the Worker, so it can't import workunit.ts (node:child_process).

3. facts was inert — my error in #109

#109 claimed the schema description meant the mechanism "doesn't ship inert." That was wrong. A JSON-schema field description is not an instruction. facts appeared exactly once in executor.ts and nowhere in the prompt, and the real δₙ run recorded zero facts while putting a genuine analytical result in output as usual.

The system prompt now tells the agent what belongs in facts (anything the run settled, written to stand alone with its numbers in it — a ruled-out approach counts), when to $retract (scaffolding describing work now done), and that state merges per key so it should never echo the whole working set back.

Verified

594 tests, 7 new. The guard checked against a C4-shaped scenario:

after proposal 1 -> checkout again:
   refused: decomposition_pending_review
   in listOpenTasks?   false
   in listAvailable?   false

after the review REJECTS:
   in listOpenTasks?   true
   in listAvailable?   true
   checkout allowed again (correct)

What #109 got right, confirmed against production across three real submits: phase2, attempt7_note and timeout_salvage survived all of them completely unchanged. Under the old replacement semantics any one of those submits could have wiped the lot.

Not in this PR

No version bump — but note src/executor.ts changed, so this does alter the published runner and will need one before release. I've left it at 0.5.0 since v0.5.0 was never tagged; the bump rides whichever PR is last before you cut it.

Still open: the informativeness guard (nothing refuses a task whose success criterion is trivially satisfiable — C4's actual mathematical failure), and surfacing facts/next_steps on the conjecture page.

🤖 Generated with Claude Code

https://claude.ai/code/session_01QQgFEPRY4W74D4eqawQ4A6